Hi,

I try to use SD together with TRX-1500 Flarm and Airconnect. On almost every flight I get an "Unexpected GPS data encountered" messages popup. It always complains about PFLAA and PFLAU sentences which as far as I can tell are position reports Flarm receives.

Unfortunately it is quite annoying that SD seems to open up 3 to 10 popups (the amount seems random...) about the same sentence and simultaneously kicks itself out of navigation mode. In my opinion this behavior does not contribute to flight safety since you have to fiddle around to much to get SD back and running! And as a side affect, the flight log is broken which means that if I used one of the time tracking functions, they won't spit out a usable result after the flight.

I noticed that behavior on all SD versions since I installed my Flarm in summer last year until today. I am running SD under Android 4.2.2 on a Samsung Galaxy Tab 2.

I also noticed that the more aircraft are in the vicinity which likely have Flarm, the more quickly the  popups appear. So the is a linear trend of Flarms flying around and SD complaining about broken sentences.

SD-Team, can you please change the way SD handles data sentences it deems to be broken in a way that allows the pilot to continue his/her duty of  navigating and to observing traffic. If you still want to track broken sentences, I suggest write them down into a log file for example. In my opinion, it is better for flight safety, to just quietly drop a sentence here and there than waiting for the user to close multiple popups and restart navigation mode.

If there is anything I can do to help you in fixing this issue, please let me know!

Florian

Thanks Florian, that's really helpful. Just testing with the first sentence it's obvious that your device is sending very bad data. The checksum is correct, which means the data was NOT corrupted in transit (SkyDemon would have ignored it in that case).

$PFLAA,0,-14084,-259068,-10144,4187,1,3C60D4,129,,209,10.0,8*55

The sixth field in that sentence has a value of 4187. That field is called IDType, and is supposed to have a value from 0 to 3.

We are correct to not only reject that data, but to do so forcefully. A device outputting such bad data has obviously got itself into a very poor state and goodness knows what other bad data it will be putting out.